Bases de données: 
Introduction et 
Objectifs 


I . Introduction 


Les entreprises gèrent des volumes de données très grands 


• Giga,Terra, Péta -octets 

• Numériques, Textuelles, Multi-média (images, films,...) 


Il faut pouvoir facilement 


• Archiver les données sur mémoires secondaires permanente 

• Retrouver les données pertinentes à un traitement 

• Mettre à jour les données variant dans le temps 


Les données sont structurées et identifiées 


• Données élémentaires ex.Votre salaire, Votre note en BD 

• Données composées ex:Votre CV, vos résultats de l'année 

• Identifiant humain ex: NSS ou machine: P262 1 5 


Qu'est-ce qu'une BD ? 


• Collection de données structurées reliées par des relations 

• Interrogeable et modifiable par des langages de haut niveau 
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Capacité 

Vv VS 

1 Coût & 
Vitesse 

5-10 ms 


80-200 ns 

3-10 ns 
2-5 ns 


La hiérarchie des mémoires 



Un accès disque est environ 1 00,000 
fois plus lent qu’un accès mémoire! 


• Eviter les accès disques 

• grande mémoire principale 

• Amortir les accès disques 

• placement des données 

• Minimiser le nombre d’accès disques 

• méthodes d’accès 





Un peu d'histoire 


Années 60: 


• Récipients logique de données ^ fichiers sur dique 

• Accès séquentiel puis sur clé 

• Lire (Nomf, Article), Ecrire (Nomf, Article) 

• Lire (Nomf, Article, Clé), Ecrire (Nomf, article, Clé) 


Années 70: 


• Avènement des Bases de Données Réseaux (BD) 

• Ensemble de fichiers reliés par des pointeurs 

• Langage d'interrogation par navigation 


Années 80: 


• Avènement des Bases de Données Relationnelles (BDR) 

• Relations entre ensemble de données 

• Langage d'interrogation par assertion logique 





Systèmes de fichiers 



Comptabilité Chirurgie 


Consultations 


Psychiatrie 


Caractéristique 

s 


Problèmes 
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Format des fichiers 



Dupond 

Turlututusqjsk 
Symptom: yyyy 
Analyses xxxx 

Turlututudhjsd 

Analyses :xx 




Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 


Problèmes 

Difficultés de gestion 
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Redondance (données 




Turlututudhjsd 

Analyses :xx 


Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 

Redondance de données 


Problèmes 

Difficultés de gestion 
Incohérence des données 
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Interrogations 




Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 

Redondance de données 
Pas de facilité d’interrogation 

Question ^développement 


Problèmes 

Difficultés de gestion 
Incohérence des données 
Coûts élevés 
Maintenance difficile 
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Pannes VA 




Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 

Redondance de données 
Pas de facilité d’interrogation 

Question ^développement 

Redondance de code 


Problèmes 

Difficultés de gestion 
Incohérence des données 
Coûts élevés 
Maintenance difficile 
Gestion de pannes ??? 
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Partage de données 




Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 

Redondance de données 
Pas de facilité d’interrogation 

Question ^développement 

Redondance de code 


Problèmes 

Difficultés de gestion 
Incohérence des données 
Coûts élevés 
Maintenance difficile 
Gestion de pannes ??? 
Partage des données ??? 
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Confidentialité 


Caractéristique 

s 

Plusieurs applications 

plusieurs formats 
plusieurs langages 

Redondance de données 
Pas de facilité d’interrogation 

Question ^développement 

Redondance de code 

Problèmes 

Difficultés de gestion 
Incohérence des données 
Coûts élevés 
Maintenance difficile 
Gestion de pannes ??? 
Partage des données ??? 
Confidentialité 11 



L’approche “Bases de données” 


Modélisation 
des données 


• ^ Eliminer la redondance de données 

• Centraliser et organiser correctement les données 

• Plusieurs niveaux de modélisation 

• Outils de conception 


Logiciel 
«Système de 
Gestion de 
Bases de 
Données» 


Factorisation des modules de contrôle des 
applications 

• - Interrogation, cohérence, partage, gestion de 
pannes, etc... 

Administration facilitées des données 


Modélisation du réel 


Réel 


Modèle 

logique 



Modèle 

conceptuel 


' Indépendant du 
modèle de données 

' Indépendant du 
SGBD 


■ Dépendant du 
modèle de données 

■ Indépendant du 
SGBD 



Modèle 

Physique 


■ Dépendant du 
modèle de données 

Dépendant du SGBD 


C 


effectue 



Codasyl 


Relationnel 


Objet 


XML 


Organisation physique des données 
Structures de stockage des données 
Structures accélératrices (index) 
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Modélisation Relationnelle (I) 




Id-D 

Nom 

Prénom 

1 

Dupont 

Pierre 

2 

Durand 

Paul 

3 

Masse 

Jean 

— 






Modélisation Relationnelle (2) 


Docteurs 


Id-D 

Nom 

Prénom 

1 

I 

Dupont 

Pierre 

2 

I 

Durand 

Paul 

3 


Masse 

Jean 

— 





Patients 


Visites 

v 


Id-D 

Id-P 

Id-V 

Date 

Prix 

1 

2 

1 

15 juin 

250 

1 

1 

2 

12 août 

180 

2 

2 

3 

13 juillet 

350 

2 

3 

4 

1 mars 

250 


Prescriptions 


Id-V 

Ligne 

Id-M 

Posologie 

1 

1 

12 

1 par jour 

1 

2 

5 

10 gouttes 

2 

1 

8 

2 par jour 

2 

2 

12 

1 par jour 

2 

3 

3 

2 gouttes 

— 

— 

— 



Id-P 

Nom 

Prénom 

Ville 

1 

Lebeau 

Jacques 

Paris 

2 

Troger 

Zoe 

Evry 

3 

Doe 

John 

Paris 

4 

Perry 

Paule 

Valenton 

— 





Médicaments 

t 


Id-M 

Nom 

Description 

1 

Aspegic 1000 


2 

Fluisédal 


3 

Mucomyst 


— 
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2. Objectifs des SGBD 
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I - Indépendance Physique 


Indépendance des programmes 
d'applications vis à vis du 
modèle physique : 


Possibilité de modifier les 
structures de stockage (fichiers, 
index, chemins d'accès, ...) sans 
modifier les programmes; 


Ecriture des applications par des 
non-spécialistes des fichiers et 

des structures de stockage; 


Meilleure portabilité des 
applications et indépendance vis à 
vis du matériel. 


Il - Indépendance Logique 

Les applications peuvent définir des vues logiques de la BD 


Gestion des médicaments 


Nombre Médicaments 


Cabinet du Dr. Masse 


Id-M 


Nom 

Description 

Nombre 

1 

Aspegic 1000 


30 

2 

1 

"luisédal 


20 

3 

Mucomyst 


230 


r 








Id -V 

Ligne 

Id -M 

Posologie 














Id -P 

Nom 

Prénom 












Id -M 

Nom 

Description 
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Avantages de l’indépendance logique 



Possibilité pour chaque application 
d'ignorer les besoins des autres 
(bien que partageant la même BD). 


Possibilité d'évolution de la base 
de données sans réécriture des 
applications : 


• ajout de champs, ajout de 
relation, renommage de 
champs. 


Possibilité d'intégrer des 
applications existantes sans 
modifier les autres. 


Possibilité de limiter les 
conséquences du partage : 

Données confidentielles. 
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III - Manipulation aisée 

La manipulation se fait via un langage déclaratif 

° La question déclare l’objectif sans décrire la méthode 
° Le langage suit une norme commune à tous les SGBD 

° SQL : Structured Query Langage 

Sémantique 

° Logique du I er ordre ++ 

Syntaxe (aperçu !) 

° SELECT <structure des résultats> 

° FROM <relations> 

° WHERE <conditions> 


IV - Des vues multiples des données 

• Les vues permettent d’implémenter 
l’indépendance logique en permettant de créer 

des relations virtuelles 

• Vue = Question stockée 

• Le SGBD stocke la définition et non le résultat 

• Exemple : 

0 la vue des patients parisiens 
0 la vue des docteurs avec leurs patients 
0 La vue des services statistiques 

o 
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V -Exécution et Optimisation 


Traduction automatique 
des questions déclaratives |H| 
en programmes m| 

procéduraux : |HB 

Optimisation 

automatique des 

questions 

|Bf Economie de l'astuce des 
|h| programmeurs 

• ^ Utilisation de l’algèbre 
relationnelle 

• Utilisation de l’aspect 
déclaratif de SQL 

• Gestion centralisée des 
chemins d'accès (index, 
hachages, ...) 

• Techniques d’optimisation 
poussées 

• milliers d'heures d'écriture 
et de maintenance de 
logiciels. 
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VI - Intégrité Logique 

Objectif : Détecter les mises à jour erronées 

Contrôle sur les données élémentaires 
° Contrôle de types: ex: Nom alphabétique 
° Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf 

Contrôle sur les relations entre les données 

° Relations entre données élémentaires: 

• Prix de vente > Prix d'achat 

° Relations entre objets: 

• Un électeur doit être inscrit sur une seule liste électorale 


Contraintes d’intégrité 


Avantages : 


• simplification du code des applications 

• sécurité renforcée par l'automatisation 

• mise en commun des contraintes 


Nécessite : 


• un langage de définition de contraintes d'intégrité 

• la vérification automatique de ces contraintes 



Transaction 






Begin 

CEpargne = CEpargne - 3000 
CCourant = CCourant + 3000 

Commit Tl 


Atomicité et Durabilité 


ATOMICITE 


DURABILITE 


Begin 

CEpargne = CEpargne - 300 


Panne 

i 


CCourant = CCourant + 3000 
Commit Tl 


Begin 

CEpargne = CEpargne - 3000 
CCourant = CCourant + 3000 
Commit Tl 

x 

Crash disque 


Annuler le débit !! 


S’assurer que le 
virement a été fait ! 



VIII - Partage des données 





• Accès concurrent aux mêmes données 


■^Conflits d’accès !! 
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Isolation et Cohérence 



• Le SGBD gère les accès concurrents 
4 Chacun à Y impression d’être seul (Isolation) 

4 Cohérence conservée (Pas de maj conflictuelles) 


29 


IX - Confidentialité 


• Objectif : Protéger les données de la BD 
contre des accès non autorisés 

• Deux niveaux : 

° Connexion restreinte aux usagers répertoriés 
(mot de passe) 

° Privilèges d'accès aux objets de la base 

• Usagers : Usager ou groupe d’usagers 

• Objets : Relation, Vue, autres objets 
(procédures, etc.) 


X - Standardisation 


• L’approche bases de données est basée sur 
plusieurs standards 

o Langage SQL (SQL I , SQL2, SQL3) 

° Communication SQL CLI (ODBC / JDBC) 

° Transactions (X/Open DTP, OSI-TP) 

• Force des standards 

° Portabilité 

° Interopérabilté 
° Applications multisources... 


3. Architecture des SGBD 


Les architectures physiques de SGBD sont très liées au mode de 
répartition. 

— BD centralisée 

— BD client/serveur 

— BD client/multi-serveurs 

— BD répartie 

— BD hétérogène 

— BD mobile 

Le challenge se déplace des Péta-bases aux Pico-bases. 

— Péta-bases => parallélisme et grandes mémoires 

— Pico-bases => faible empreinte et forte sécurité 


Architecture centralisée 




données 


Je le 


Terminaux passifs 


réseau 



Mainframe 
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Architecture client 




Appli n 



SGBD 


code 


données 


Je le 


serveur 


Clients intelligents 


réseau 













Architecture Client-Multiserveurs 



SGBD 1 


code données 





SGBD 2 


code données 












Architecture répartie 

















Architecture mobile 




Données répliquées 
et/ou personnelles 



Clients intelligents 
mobiles 


Réseau sans fil 








4.Applications traditionnelles 
des SGBD 


OLTP (On Line Transaction Processing) 


• Cible des SGBD depuis leur existence 

• Banques, réservation en ligne ... 

• Très grand nombre de transactions en parallèle 

• Transactions simples 


OLAP (On Line Analytical Processing) 


• Entrepôts de données, DataCube, Data Mining ... 

• Faible nombre de transactions 

• Transactions très complexes 
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Evolution des BD 


BD 


BD 


Capacité 


Prix 


d’entreprise 



personnelles 




i 


i 



BD ‘light’ PicoDBMS 
(PDA / Tél.) carte à puce 
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Nombre 








LE MODELE RELATIONNEL 


Inventé par T. Codd (IBM Recherche) 

Publication ACM 1970 

1 . Concepts pour la description 

2. Concepts pour la manipulation 

3. Concepts additionnels 


1 . CONCEPTS DESCRIPTIFS 


Ensemble de concepts pour formaliser la 
description d'articles de fichiers plats 

Modèle standardisé mais extensible 

■ Introduction de types de données variés (SQL2) 

■ Introduction de la dynamique (produits, SQL3) 

■ Introduction des objets (SQL3) 


Domaine 


♦ ENSEMBLE DE VALEURS 

♦ Exemples: 

■ ENTIER 

■ REEL 

■ CHAINES DE CARACTERES 

■ EUROS 

■ SALAIRE = { 4 000. . 1 00 000 } 

■ COULEUR^ {BLEU, BLANC, ROUGE} 
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Produit cartésien 


LE PRODUIT CARTESIEN Dix D2x ... x 
Dn EST L’ENSEMBLE DES TUPLES (N- 
UPLETS) <Vl,V2,....Vn> TELS QUE ViD s 
Di 

Exemple: 

■ DI = {Bleu, Blanc, Rouge} 

■ D2 = {Vrai, Faux} 


Bleu Vrai 
Bleu Faux 
Blanc Vrai 
Blanc Faux 
Rouge Vrai 
Rouge Faux 


Relation 


♦ SOUS-ENSEMBLE DU PRODUIT CARTESIEN 
D'UNE LISTE DE DOMAINES 


♦ Une relation est caractérisée par un nom 


♦ Exemple: 

- DI = COULEUR 
■ D2 = BOOLEEN 


Coulvoiture 

Coul 

Choix 


Bleu 

Faux 


Blanc 

Vrai 


Rouqe 

Vrai 
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Attribut 


♦ VISION TABULAIRE DU RELATIONNEL 

■ Une relation est une table à deux dimensions 

■ Une ligne est un tuple 

■ Un nom est associé à chaque colonne afin de la repérer 
indépendamment de son numéro d'ordre 

♦ ATTRIBUT 

■ nom donné à une colonne d'une relation 

■ prend ses valeurs dans un domaine 
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Clé 


♦ GROUPE D'ATTRIBUTS MINIMUM QUI 
DETERMINE UN TUPLE UNIQUE DANS UNE 
RELATION 

♦ Exemples: 

- NSS DANS PERSONNE 

♦ CONTRAINTE D'ENTITE 

■ Toute relation doit posséder au moins une clé documentée 
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Schéma 


NOM DE LA RELATION, LISTE DES ATTRIBUTS AVEC 
DOMAINES, ET LISTE DES CLES DUNE RELATION 

Exemple: 

■ voiture dd: Int , nom: texte, annee Cons: entier) 

■ Par convention, la clé primaire est soulignée 

SCHEMA DUNE BD RELATIONNELLE 

■ C'est l'ensemble des schémas des relations composantes 


Clé Etrangère 


GROUPE D'ATTRIBUTS DEVANT 
APPARAITRE COMME CLE DANS UNE AUTRE 
RELATION 

Les clés étrangères définissent les contraintes 
d'intégrité référentielles 

■ Lors d'une insertion, la valeur des attributs doit exister dans 
la relation référencée 

■ Lors d'une suppression dans la relation référencée les tuples 
référençant doivent disparaître 

■ Elles correspondent aux liens entité-association obligatoires 


Exemple de Schéma 


EXEMPLE 

personnes (NB, NOM, PRENOM, TYPE) 

the (Nthe, nom, couleur, origine) 

consommation(NB, Nthe, DATE, 

QUANTITE) 

CLES ETRANGERES 

consommation.Nthe REFERENCE the.Nthe 
consmmation.NB REFERENCE personne.NB 


Concepts Descriptifs : Bilan 


♦ RELATION ou TABLE 

♦ ATTRIBUT ou COLONNE 

♦ DOMAINE ou TYPE 

♦ CLE 

♦ CLE ETRANGERE 


Questions ? 
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Synthèse : Create Table 


♦ CREATION DES TABLES EN SQL 

■ CREATE TABLE <relation name> 

■ (<attribute definition>+) 

- [ { PRIM AR Y KE Y I UNIQUE } (<attribute name>+)] 

♦ avec : 

■ <attribute definition> ::= <attribute name> <data type> 

- [NOTNULL [{UNIQUE IPRIMAR Y KEY}] ] 

♦ Exemple : 

- CREATE TABLE the 

- ( Nthe INTEGER PRIMARY KEY 

- Nom VARCHAR 


• • • • 
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2. CONCEPTS 
MANIPULATOIRES 


♦ Un ensemble d'opérations formelles 

■ Algèbre relationnelle 

♦ Ces opérations permettent d'exprimer toutes les 
requêtes sous forme d'expressions algébriques 

♦ Elles sont la base du langage SQL 

■ Paraphrasage en anglais des expressions relationnelles 

♦ Ces opérations se généralisent à l'objet 

■ Algèbre d'objets complexes 
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Opérations Ensemblistes 

UNION notée u 
Produit cartésien notée X 
DIFFERENCE notée — 


Opérations Spécifiques 

Projection 


♦ Elimination des 


personne prénom 


dateNaiss villeNaiss 


attributs non désirés et 
suppression des tuples 
en double 


ahmed 

1983 

Casablanca 

sara 

1979 

rabat 

khalid 

1983 

oujda 

Amina 

1986 

oujda 


* Relation -> Relation Ttnom.dateNai 


notée: 

n Al,A2,...Ap (R) 


7l(personne) 

nom 

dateNaiss 


ahmed 

1983 


sara 

1979 


khalid 

1983 


Amina 

1986 
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Restriction 


♦ Obtention des tuples de R satisfaisant un critère Q 

♦ Relation ->Relation, notée g q (R) 

♦ Q est le critère de qualification de la forme : 

■ Ai 0 Valeur 

■ 0 =□ { =, <, >=, >, <=, !=} 
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Exemple de Restriction 


ŒdateNaiss>1983 


personne 

prénom 

dateNaiss 

villeNaiss 


Amina 

1986 

oujda 
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Jointure 


♦ Composition des deux relations sur un domaine commun 

♦ Relation X Relation ->Relation 

■ notée 

♦ Critère de jointure M 

■ Attributs de même nom égaux : 

• Attribut = Attribut 

• Jointure naturelle 

■ Comparaison d’attributs : 

• Attribut 1 0D Attribut2 

• héta-jointure 
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SQL 


♦ Une requête SQL est un paraphrasage d'une expression de 
l'algèbre relationnelle en anglais 

♦ Requête élémentaire : 

SELECT Al, A2, ...Ap 
FROM RI, R2, ...Rk 

WHERE Q [{UNION |INTERSECT | EXCEPT } . . . ] 

♦ □ Sémantique du bloc select : 

PROJECT Al, A2,...Ap( 

RESTRICT Q ( 

PRODUIT ( RI, R2, Rk) ) ) 
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3 . CONCEPTS 
ADDITIONNELS 


Ensemble de concepts pour : 

■ Etendre les fonctionnalités de manipulation 

■ Décrire les règles d'évolution des données 

■ Supporter des objets complexes (SQL3) 

Introduits progressivement dans le modèle 

■ Complique parfois le modèle 

■ Standardisés au niveau de SQL3 (1999) 

■ Des extensions multiples . . . 


Fonction et Agrégat 


♦ FONCTION 

■ Fonction de calcul en ligne appliquée sur un ou plusieurs 
attributs 


♦ AGREGAT 

■ Partitionnement horizontal d'une relation selon les valeurs 
d'un groupe d'attributs, suivi d'un regroupement par une 
fonction de calcul en colonne (SUM, MIN, MAX, A VG, 
COUNT, ...) 
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4. CONCLUSION 


Un ensemble de concepts bien compris et bien 
formalisés 

Un modèle unique, riche et standardisé 

■ intégration des BD actives 

■ intégration des BD objets 

Un formalisme qui s'étend plutôt bien 

■ algèbre d'objets 

Un langage associé défini à plusieurs niveaux 
- SQL1, 2, 3 


LE LANGAGE DE REQUETES 

SQL 

INTRODUCTION 


♦Origines et Evolutions 
♦SQL1 86: la base 
♦SQL1 89: l'intégrité 


1 . Origines et Evolutions 


SQL est dérivé de l'algèbre relationnelle et de SEQUEL 

Il a été intégré à DB2, ORACLE, MySQL, SQLServer, 
etc. 

Il existe trois versions normalisées, du simple au 
complexe : 

■ SQL1 86 version minimale 

■ SQL1 89 (intégrité) 

■ SQL2 (92) langage complet 

Une version 3 étendue (objets, règles) est la norme 99. 
La plupart des systèmes supportent SQL2 complet 


Opérations 


♦ Opérations de base 

- SELECT, INSERT, UPDATE, DELETE 

♦ Opérations additionnelles 

■ définition et modification de schémas 

■ définition de contraintes d'intégrité 

■ définition de vues 

■ accord des autorisations 

■ gestion de transactions 
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Organisation du Langage 


SQL comprend quatre parties : 

Le langage de définition de schéma (Tables, 
Vues, Droits) 

Le langage de manipulation (Sélection et mises à 
jour) 

La spécification de modules appelables 
(Procédures) 

L'intégration aux langages de programmation 


SQL1 - 86 


♦ LANGAGE DE DEFINITIONS DE DONNEES 

. CREATE TABLE 
. CREATE VIEW 

♦ LANGAGE DE MANIPULATION DE DONNEES 

. SELECT OPEN 

- INSERT FETCH 

. UPDATE CLOSE 

. DELETE 

♦ LANGAGE DE CONTROLE DE DONNEES 

- GRANT et REVOKE 

- BEGIN et END TRANSACTION 

- COMMIT et ROLLBACK 
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2. SELECT: Forme Générale 


■ SELECT <liste de projection> 

■ FROM <liste de tables> 

■ [WHERE <critère de jointure> AND <critère de restriction>] 

■ [GROUP B Y <attributs de partitionnement>] 

■ [HAVING <citère de restriction>] 

Restriction : 

■ arithmétique (=,<,>, >,<□) 

■ textuelle (LIKE) 

■ sur intervalle (BETWEEN) 

■ sur liste (IN) 

Possibilité de blocs imbriqués par : 

71 IN, EXISTS, NOT EXISTS, ALL, SOME, ANY 


Forme générale de la condition 


<search condition> [NOT] 

<nom_colonne> 0 constante | <nom_colonne> 

<nom_colonne> LIKE <modèle_de_chaîne> 

<nom_colonne> IN <liste_de_valeurs> 

<nom_colonne> 0 (ALL | AN Y | SOME) <liste_de_valeurs> 
EXISTS <liste_de_valeurs> 

UNIQUE <liste_de_valeurs> 

<tuple> MATCH [UNIQUE] <liste_de_tuples> 

<nom_colonne> BETWEEN constante AND constante 
<search condition> AND | OR <search condition> 

avec 

0 ::= < | = | > | > | < | <> 

Remarque: <liste_de_valeurs> peut être dynamiquement déterminée par une requête 
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3. Les Mises à Jour 


♦ INSERT 

■ Insertion de lignes dans une table 

■ Via formulaire où via requêtes 

♦ UPDATE 

■ Modification de lignes dans une table 

♦ DELETE 

■ Modification de lignes dans une table 


8 


Commande INSERT 


INSERT INTO <relation name> 

[( attribute [,attribute] . . . )] 

{VALUES <value spec.> [, <value spec>] ...I <query spec.>} 


Commande UPDATE 


UPDATE <relation name> 

SET <attribute = {value expression I NULL} 
[<attribute> = {value expression | NULL}] . . . 
[WHERE <search condition>] 
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Commande DELETE 


DELETE FROM <relation name> 
[WHERE <search condition>] 


4. Contraintes d'intégrité 


Contraintes de domaine 

■ Valeurs possibles pour une colonne 

Contraintes de clés primaires 

■ Clé et unicité 

Contraintes référentielles(clé étrangères) 

■ Définition des liens inter-tables 


SQL1 - 89 : INTEGRITE 


♦ VALEURS PAR DEFAUT 

■ CREATE TABLE The 

. ( Nthe INT UNIQUE, 

■ origine CHAR(IO), 

■ annee INT, 

■ ) 

♦ CONTRAINTES DE DOMAINES 

■ SALAIRE INT CHECK BETWEEN 6000 AND 100000 
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SQL 1 - 89 : 

Contrainte référentielle 

Clé primaire et contrainte référentielle 

■ A discuter 


SQL1 - 89 : Création de table 


CREATE TABLE <nom_table> 
(<def_colonne> * 
[<def_contrainte_table>*]) ; 


< def_colonne > ::= 

<nom_colonne> < type nom_domaine > 

[CONSTRAINT nom_contrainte 

< NOT NULL | UNIQUE | PRIMARY KEY | 

CHECK (condition) | REFERENCES nom_table (liste_colonnes) > ] 

< def_contrainte_table > ::= CONSTRAINT nom_contrainte 

< UNIQUE (liste_colonnes) | PRIMARY KEY (liste_colonnes) | 

CHECK (condition) | 

FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes) 
[NOT] DEFERRABLE 


Autre création de tables 


CREATE TABLE EXPEDITIONS 
( numExp INTEGER PRIMARY KEY 
date_exp DATE, 
qte QUANTITE, 

CONSTRAINT refCom FOREIGN KEY numExp 
REFERENCES COMMANDES (numCom) DEFERRABLE 

) ; 

L'association d'un nom à une contrainte est optionnelle. 

Ce nom peut être utilisé pour référencer la contrainte (ex: messages 
d'erreurs). 
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5 . CONCLUSION 


♦ SQL1 est un standard minimum 

♦ Les versions étendues: 

■ SQL2 = Complétude relationnelle 

■ SQL3 = Support de l'objet 

♦ Sont aujourd'hui intégrées dans les grands SGBD 
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LA NORMALISATION DE SQL 


♦ Groupe de travail ANSI/X3/H2 et ISO/IEC JTC 1/SC2 

♦ Documents ISO : 

- SQL1 - 86 : Database Language SQL X3.135 ISO-9075-1987) 

■ SQL1 - 89 : Database Language SQL with Integrity Enhancement X3.168 ISO- 
9075-1989 

- SQL2 - 92 : Database Language SQL2 X3.135 ISO-9075-1992 

♦ Arguments pour : 

■ Réduction des coûts d'apprentissage 

■ Portabilité des applications 

■ Longévité des applications 

■ Langage de communication inter-systèmes 

♦ Arguments contre : 

■ Manque de rigueur théorique 

■ Affaiblit la créativité 
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POSITION DES VENDEURS 
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1 


^ Vue d’ensemble 


b Extraction de données à l'aide de l'instruction 
SELECT 


b Filtrage des données (Restriction) 

Mise en forme des ensembles de résultats 


2 




Extraction de données: 
utilisation de l’instruction 

SELECT 


a La liste de sélection indique les colonnes 

a La clause WHERE indique la condition limitant 
la requete 

a La clause FROM indique la table 


^^hExt faction de données: 
^BÎBt|f[cat[on des colonnes 

s SELECT emp_ID, nom, prénom 
a FROM employé 




Extraction de données: 
llisation de la clause WHERE 
r spécifier des lignes 


0 SELECT emp_ID, nom 
0 FROM employé 
0 WHERE empl_ID=5 


^M^iltrage des données 

a Utilisation des opérateurs de comparaison 

a Utilisation des comparaisons de chaines 

a Utilisation des opérateurs logiques 

a Extraction d'une plage de valeurs 

a Utilisation d'une liste de valeurs comme critère 
de recherche 

a Extraction de valeurs inconnues 



ilt rage 




Type de filtre 


Opérateurs de comparaison 
Comparaison de chaines 
Opérateurs logiques 
Plage de valeurs 
Liste de valeurs 
Valeur inconnues 


es données 


Condition de recherche 


=,<,>,<=,>= et <> 
LIKE et not LIKE 


AND, OR, NOT 
BETWEEN et NOT BETWEEN 
IN et NOT IN 
IS NULL et IS NOT NULL 







Filtrage des données: 
Hsatîon des opérateurs de 
comparaison 



b SELECT prénom, ville 
b FROM employé 
b WHERE pays= / MAROC' 
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Filtrage des données: 
jsation des comparaison de 

chaînes 

s SELECT nom_entreprise 
a FROM client 

a WHERE nom_entreprise LIKE ' % MAROC % ' 




ui 


Filtrage des données: 
^■Utilisation des opérateu 
PHII logiques 

0 SELECT produit_ID, produit_nom 
0 FROM produit 

0 WHERE (produit_nom LIKE 'toto' OR 
produit_ID=20) AND (PU_HT>100) 



Filtrage des données: 
tÆion d’une plage de valeurs 


h SELECT produit_nom, PU_HT 
s FROM produit 

s WHERE PU_HT BETWEEN 10 AND 20 
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Filtrage des données: 
isation d’une liste de valeurs 
ie critère de recherche 


a SELECT nom_entreprise, pays 
b FROM fournisseurs 
b WHERE pays IN (' MAROC /ALGERIE') 
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des données: 
de valeurs NULL 

a SELECT nom_entreprise, fax 
a FROM fournisseurs 
a WHERE fax IS NULL 


Filtrage 
Extraction 


iflise en forme des ensembles de 

résultats 

b Tri des données 
b Suppression des doublons 
b Changement des noms de colonne 
b Utilisation de littéraux 
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Mise en forme : 
Tri des données 

b SELECT produit_ID, nom_produit, 
categorie_ID 

b FROM produit 

b ORDER BY categorie_ID 
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Mise en forme : 
oppression des doublons 


0 SELECT DISTINCT pays 
0 FROM fournisseurs 
0 ORDER B Y PAYS 
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Mise en forme : 
angement des noms 
I colonne 



a SELECT nom as N, prénom as P, employe_ID 
as 'EMPLOYE ID' 

a FROM employé 
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Mise en forme : 
Hp^Jtilisatlon de littéraux 

b SELECT nom, 'NUMERO IDENTIFICATION 
employe_ID 

b FROM employé 
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Regroupement 




Utilisation de fonctions 





agrégation 



Fonction d'agrégation 

Desciption 

AVG (expr) 

Moyenne de expr 

COUNT (* | expr) 

Nombre de ligne 

MAX (expr) 

Maximum de expr 

MIN (expr) 

Minimum de expr 

SUM (expr) 

Somme de exp 

STDEV (expr) 

Ecart type de exp 

VAR IANCE(expr) 

Variance de exp 






^^Utilisation de fonctions 
Wm- d’agrégation 

h Exemple 

Select SUM (Quantité) 

From detail_commande 




Utilisation de la clause 
k. GROUP BY 


a Select produit_ID, Commande_ID, Quantité 
a From detail_commande 


a Select produit, SUM(Quantite) 
a From detail_commande 
b GROUP BY produit_ID 



Utilisation de la clause 
k GROUP BY 


Produit_ID 

CommandeJD 

Quantité 

1 

1 

5 

1 

4 

10 

1 

7 

20 

2 

1 

5 

2 

2 

10 



Produit_ID 

Total_Qte 

1 

35 

2 
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^fcCROUP BY avec Havïng 

b SELECT produit_ID, SUM (Quantité), 
b From detail_commande 
b GROUP B Y produit_ID 
b HAVING SUM (Quantité) >30 




Objectif 

Décrire l'aspect LMD (langage de manipulation des 
données) de MySQL. Nous verrons que SQL propose 
trois instructions pour manipuler des données : 

0 nsertion d sRÜ^Bæments : INSERT ; 

0 nodification de dŒ^ées : UPDATE ; 

0 oppression d'enregistrements : DELETE (et 

^Kuncate). 

Il existe d'autres possibilités pour insérer des 

données en utilisant des outils d'importation ou de 
migration, citons MySQL Migration Toolkit, 
SQLPorter, Navicat, Intelligent Converters et MySQL 
Data Import de la société EMS. 




nregistrements 

(INSERT) 


Insertions 


d’enregi 

(INSERT) 


strements 


Pour pouvoir insérer des enregistrements dans 
une table, il faut que vous ayez reçu le 
privilège INSERT. Il existe plusieurs 
possibilités d'insertion : l'insertion monoligne 
qui ajoute un enregistrement par instruction et 
l'insertion multiligne qui insère plusieurs 
enregistrements par une requête. 


eigner toutes les colonnes 


ompagme 

Camparols', 'Singapour', 


H 


^ise 


g 


ner certaines colonnes 


0 Insérons deux lignes dans la table Compagnie en 
ne précisant pas toutes les colonnes. La première 
insertion affecte implicitement la valeur par défaut 
à la colonne ville. La deuxième donne 
explicitement la valeur NULL à la colonne nrue. 

HT INTO Compagnie 

^ ES ('AC', 10, 'Gambetta', DEFAULT, 

St ance'); 


RT IN 


INSERT INTO Compagnie(comp, nrue, rue. 



VALUES ('AF', 
Air’); 


NULL 





s enregistrements 

Le script suivant ajoute trois nouvelles 
compagnies en une seule instruction INSERT. 

HtKT INTO Compagnie VALUES 

|^^^p',9,'Salas','Munich','Luftansa'), 

( 1 ' , 1 , ' Kangour oo ' , 1 Sydney',' Quantas ' ) , 

('SNCM',3,'P. Paoli','Bastia','Corse Air'); 




Enumérations 


Le type ENUM est considéré comme une liste de chaînes de 
caractères. Toute valeur d'unecolonne de ce type devra appartenir à 
cette liste établie lors de la création de la table. Supposons qu'on 
recense quatre types possibles de diplômes ('BTS', 'DUT', 'Licence' et 
'INSA') pour chaque étudiant. On ne stocke qu'un seul diplôme par 
étudiant. 

HfeATE TABLE UnCursus 
lum CHAR(4), nom CHAR(15), diplôme 
('BTS'/DUT'/Licence'/INSA') , 

CONSTRAINT pk_Cusus PRIMARY KEY(num)); 

INSERT INTO UnCursus VALUES 
('El', 'F. Brouard', ('BTS')); 


INSERT INTO UnCursus VALUES 
('E2', 'F. Degrelle', 'Licence'); 



■k Dates et heures 

Les types suivants permettent de stocker des 
moments ponctuels (dates, dates et heures, 
années, et heures). Les fonctions NOW() et 
SYSDATE0 retournent la date et l'heure 
courantes. Dans une procédure ou un déclencheur 
SYSDATE est réévaluée en temps réel, alors que 
NOW désignera toujours l'instant de début de 
traitement 



Dates et 


reures 


DATE 

Sur 3 octets. L'affichage est au format 
' YYYY -MM-DD' . 

DATETIME 

Sur 8 octets. L'affichage est au format 
'YYYY-MM-DD HH:MM:SS'. 

YEAR 

Sur 1 octet ; Tannée est considérée sur 
2 ou 4 positions (4 par défaut). Le 
format d'affichage est 'YYYY'. 

TIME 

L'heure au format 'HHH:MM:SS' sur 
3 octets. 

TIMESTAMP 

Estampille sur 4 octets (au format 
'YYYY-MM-DD HH:MM:SS') ; mise à 
jour à chaque modification sur la 
table. 





Dates et heures 




À rE TA BI E i ilôt» 

/brevet VARCHAR(6), nom VARCHAR(20), 
I :eNaiss DATE, 

HaHVol DECIMAL(7,2),dateEmbauche 
%ATETIME, compa VARCHAR(4), 

OTNSTRAINT pk_Pilote PRIMARY 
KE Y (brevet)); 


Ltions de 
fiPDATE 


colonnes 


Modifications de colonnes 
^ UPDATE 


L'instruction UPDATE permet la mise à jour des 
colonnes d'une table. Pour pouvoir modifier 

des enregistrements d'une table, il faut que cette 
dernière soit dans votre base ou que vous 

ayez reçu le privilège UPDATE sur la table. 



Exemple : 

Modifions la compagnie de code 'AN1' en 
affectant la valeur 50 à la colonne nrue. 


^ÇDATE Compagnie SET nrue = 50 WHERE 
comp = 'AN1'; 



ion de plusieurs colonnes 


m Exemple: 



DATE Compagnie SET nrue = 14, ville 
A JLT WHERE comp = 1 AN2 1 ; 


UPDATE Pilote SET dateNaiss = 1967-03-25 

12 : 35 : 00 ' 

WHERE brevet = 'PL-l' 










Instruction DELETE 


Les instructions DELETE permet de supprimer un 
ou plusieurs enregistrements d'une table. Pour 
pouvoir supprimer des enregistrements dans une 
table, il faut que cette dernière soit dans votre 
base ou que vous ayez reçu le privilège DELETE 
sur la table. 



ELETE 
LETE 


FROM Pilote WHERE compa = 'AF 1 ; 
FROM Compagnie WHERE comp = 





r r r 


int égrité reterenti 

MlfcJMÉÉà. 


L'intégrité référentielle forme le cœur de la cohérence 
d'une base de données relationnelle. Cette intégrité 
est fondée sur la relation entre clés étrangères et clés 
primaires (ou candidates : colonnes indexées uniques 
et non nulles) qui permettent de programmer des 
règles de gestion. 

Ce faisant, la plupart des contrôles côté client 
(interface) sont ainsi déportés côté serveur. 


!!!! A continuer... 



JCTNTURE CUITE) 
Sous-requêtes 




inture procédurale 
(Sous requêtes) 


Les jointures procédurales sont écrites par des 
requêtes qui contiennent des 

(SELECT imbriqué). 

vl ne contient qu'une seule table . 


SELECT colonnes! ’ablel FROM 
[ nomBase.]nomTablel 

WHERE colonne(s) \ expression(s) {IN \ = \ 
opérateur } 

ïCT colonne(s)delaTableTtROM [nomBase.]nomTable2 
colonne(s) \ expression(s) {IN | = | opérateur } 
ELECT 

(conditionsTable2)] 


[AND ( conditions! ablel )]; 





Jointures procédurales 

Sous- in te rrbgatio n s 


momolignes 



Voir Exemples!! 
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Jointures procédurales 

Sous-interrogations T 







6 


|JEÿ opéfateurs multilignes sont 

les suivants (I /2) : 

1. compare un élément à une donnée 

quelconque ramenée par la sous- 

interrogation. Cet opérateur est utilisé pour 
les équijointures et les autojointures. 

2. compare l'élément à chaque donnée 

ramenée par la sous-interrogation. L'opérateur 
« » . L'opérateur « 

» signifie « inférieur à 

. L'opérateur « » signifie « 

mérieur à au moins une des valeurs ». 
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|JE£ opétateurs multilignes sont 
B^^les suivants (1/2) : 

3. compare l'élément ceux ramenés 

par la sous-interrogation. L'opérateur « 

» signifie » et « 

» signifie « ». 
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Voir Exemples!! 
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Sous-i interrogations 
synchronisées 


10 



Sous-interrogations 

synchronisées 

SELECT aliasl.c 
FROM nomTablel aliasl 
WHERE colonne(s) opérateur 

(SELECT ciliaÊÈ^.^ 

^ | FROM nomTablel alias2 

WHERE aliasl .x opérateur aliasl.y) 

[AND ( conditions! 'ablel )]; 


il 




Sous-î interrogation s 
hronisées: les opérateurs 



EKISTS & NOT EXISTS 



b L'opérateur permet 

. La valeur FALSE est retournée si aucun 
enregistrement n'est extrait par la sous- 
interrogation 

b L'opérateur retourne la valeur TRUE 

si aucun enregistrement n'est extrait par la sous- 
interrogation. 
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Voir Exemples!! 
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Question? 


14 




Exemples de jointures 


Notre premier exemple 

Compagnie 


Comp 

nrue 

rue 

ville 

nomComp 

AF 

122 

Paris 

Paris 

Air France 

RAM 

7 

BD des FAR 

Casablanca 

Royal Air Maroc 

SING 

1 

Camparols 

Singapour 

Singapore AL 


Pilote 


brevet 

nom 

nbVol 

compa 

chefPil 

PLI 

Pierre lamo 

450 

AF 

PL4 

PL2 

Didier Linx 

900 

AF 

PL4 

PL3 

Hamid Lmrabet 

1000 

RAM 


PL4 

Henri alqui 

3400 

AF 


PL5 

Ahmed Saadi 

950 

RAM 



2 














Deux tables à mettre en jointure 


Comp 


nrue rue 



ville 

nomComp 

Paris 

Air France 

Casablanca 

Royal Air Maroc 

Singapour 

Singapore AL 


brevet nom 


PLI Pierre lamo 

PL2 Didier Linx 

PL3 Hamid Lmrabet 

PL4 Henri alqui 

PL5 Ahmed Saadi 


nbVol compa 



chefPil 


PL4 

PL4 
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Deux tables à mettre en jointure 


Comp 

nrue 

rue 

ville 

nomComp 

AF 

122 

Paris 

Paris 

Air France 

RAM 

7 

BD des FAR 

Casablanca 

Royal Air Maroc 

SING 

1 

Camparols 

Singapour 

Singapore AL 


l 1 


brevet 

nom 

nbVol 

compa 

chefPil 

PLI 

Pierre lamo 

450 

AF 

PL4 

PL2 

Didier Linx 

900 

AF 

PL4 

PL3 

Hamid Lmrabet 

1000 

RAM 


PL4 

Henri alqui 

3400 

AF 


PL5 

Ahmed Saadi 

950 

RAM 
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Equijointure 



• Requête 1: 1 identité des pilotes de la compagnie 
de nom 'Air France' ayant plus de 500 heures de 
vol? 

• Requête 2: les coordonnées des compagnies qui 
embauchent des pilotes de moins de 500 heures 
de vol 
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LECT brevet, nom 
FROM Pilote, Compagnie 
WHERE comp=compa 

AND nomComp = 'Air France' AND nbFIVol > 
500; 

SELECT cpg.nomComp, cpg.nrue, 
cpg.rue, cpg.ville 
FROM Pilote pii. Compagnie cpg 
WFIERE cpg.comp=pil.compa 
AND pil.nbHVol < 500; 
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SELECT brevet, nom 
FROM Compagnie 

JOIN Pilote ON comp = compa 

WHERE nomComp = 'Air France' 
AND nbHVol > 500; 


8 



SELECT nomComp, nrue, rue, ville 
FROM Compagnie 

INNER JOIN Pilote ON comp = compa 

WHERE nbHVol >500; 
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Autojointure 
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Autojointure 


l 1 


brevet 

nom 

nbVol 

compa 

chefPil 

PLI 

Pierre lamo 

450 

AF 

PL4 

PL2 

Didier Linx 

900 

AF 

PL4 

PL3 

Hamid Lmrabet 

1000 

RAM 


PL4 

Henri alqui 

3400 

AF 


PL5 

Ahmed Saadi 

950 

RAM 










• Requête 3: 1 identité des pilotes placés sous la 
responsabilité des pilotes de nom 'Alqui'? 

• Requête 4: la somme des heures de vol des 
pilotes placés sous la responsabilité des chefs 
pilotes de la compagnie de nom 'Air France'? 
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SELECT pl. brevet, pl.nom 
FROM Pilote pl, Pilote p2 
WHERE pl.chefPil = p2. brevet 
AND p2.nom LIKE '%Alqui%'; 


SELECT SUM(pl.nbHVol) 

FROM Pilote pl, Pilote p2, 
Compagnie cpg 
WHERE pl.chefPil = p2. brevet 
AND cpg.comp = p2.compa 
AND cpg.nomComp = 'Air France'; 
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SELECT pl. brevet, pl.nom 
FROM Pilote pl 

JOIN Pilote p2 

ON pl.chefPil = p2. brevet 

WHERE p2.nom LIKE '%Alqui%'; 


14 



SELECT SUM(pl.nbHVol) 

FROM Pilote pl 

JOIN Pilote p2 

ON pl.chefPil = p2. brevet 

JOIN Compagnie 

ON comp = p2.compa 

WHERE nomComp = 'Air France'; 
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V Jointures 

procédurales 
(Sous-requêtes) 
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Notre exemple avec les sous requêtes 

Compagnie 


Comp 

nrue 

rue 

ville 

nomComp 

AF 

122 

Paris 

Paris 

Air France 

RAM 

7 

BD des FAR 

Casablanca 

Royal Air Maroc 

SING 

1 

Camparols 

Singapour 

Singapore AL 


Pilote 


brevet 

nom 

nbVol 

compa 

chefPil 

PLI 

Pierre lamo 

450 

AF 

PL4 

PL2 

Didier Linx 

900 

AF 

PL4 

PL3 

Hamid Lmrabet 

1000 

RAM 


PL4 

Henri alqui 

3400 

AF 


PL5 

Ahmed Saadi 

950 

RAM 
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• Requête 1: : l'identité des pilotes de la compagnie 
de nom 'Air France' ayant plus de 500 heures de 
vol? 
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SELECT brevet, nom FROM Pilote 
WHERE 

compa = (SELECT comp 
FROM Compagnie 
WHERE nomComp = 'Air France') 


AND nbHVol>500; 
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\ Sous-interrogations 
multi-lignes : IN, ALL 
& ANY 


Les opérateurs: IN ALL,ANY 


Exemple à traiter 


immat 

typeAv 

nbHvol 

compa 

Al 

A320 

1000 

AF 

A2 

A330 

1500 

AF 

A3 

A320 

550 

RAM 

A4 

A340 

1800 

RAM 

A5 

A340 

200 

AF 

A6 

A330 

100 

AF 


VOIR AUSSI TD ? 








Vous AVEZ DES 
QUESTIONS ? 




MERISE 

Modélisation des 


0 


Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Cycle de vie 


« La qualité du processus de fabrication est garante de la qualité 

du produit » 

9 Pour obtenir un logiciel de qualité, il faut en maîtriser le 
processus d’élaboration 

® La vie d’un logiciel est composée de différentes étapes 
o La succession de ces étapes forme le cycle de vie du logiciel 
® Il faut contrôler la succession de ces différentes étapes 


< □ ► < g ► < = ► ◄ = ► -O q,o 


Pierre Gérard MERISE 




Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Etude de faisabilité 


9 Déterminer si le développement proposé vaut la peine d’être 
mis en oeuvre, compte tenu de attentes et de la difficulté de 
développement 

o Etude de marché : Déterminer s’il existe un marché potentiel 
pour le produit. 
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Gérard 


MERISE 




Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Spécification 


® Déterminer les fonctionnalités que doit posséder le logiciel 
o Collecte des exigences : obtenir de l’utilisateur ses exigences 
pour le logiciel 

o Analyse du domaine : déterminer les tâches et les structures 
qui se répètent dans le problème 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Organisation du projet 


® Déterminer comment on va développer le logiciel 

® Analyse des coûts i établir une estimation du prix du projet 
® Planification : établir un calendrier de développement 
® Assurance qualité du logiciel déterminer les actions qui 
permettront de s’assurer de la qualité du produit fini 
® Répartition des tâches : hiérarchiser les tâches et sous-tâches 
nécessaires au développement du logiciel 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Conception 


® Déterminer la façon dont dont le logiciel fournit les différentes 
fonctionnalités recherchées 
© Conception générale 

9 Conception architecturale : déterminer la structure du système 
9 Conception des interfaces : déterminer la façon dont les 
différentes parties du système agissent entre elles 

9 Conception détaillée : déterminer les algorithmes pour les 
différentes parties du système 
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Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Implémentation 


® Ecrire le logiciel 
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Pi< 


Gérard 


Processus de développement d’un logiciel 
_a méthode MERISE 
_e Projet 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 

Tests 


® Essayer le logiciel sur des données d’exemple pour s’assurer 
qu’il fonctionne correctement 

® Tests unitaires : faire tester les parties du logiciel par leurs 
développeurs 

® Tests d’intégration : tester pendant l’intégration 
® Tests de validation : pour acceptation par l’acheteur 
® Tests système : tester dans un environnement proche de 
l’environnement de production 
9 Tests Alpha : faire tester par le client sur le site de 
développement 

9 Tests Bêta : faire tester par le client sur le site de production 
9 Tests de régression : enregistrer les résultats des tests et les 
comparer à ceux des anciennes versions pour vérifier si la 
nouvelle n’en a pas dégradé d’autres 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Livraison 


o Fournir au client une solution logicielle qui fonctionne 
correctement 

9 Installation : rendre le logiciel opérationnel sur le site du client 
9 Formation : enseigner aux utilisateurs à se servir du logiciel 
9 Assistance : répondre aux questions des utilisateurs 
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Processus de développement d’un logiciel 
La méthode MERISE 
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Modèles conceptuels 
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Maintenance 


® Mettre à jour et améliorer le logiciel pour assurer sa pérénité 

o Pour limiter le temps et les coûts de maintenance, il faut 
porter ses efforts sur les étapes antérieures 



Répartition 
effort dév. 

Origine des 
erreurs 

Coût de la 
maintenance 

Définition des 
besoins 

6% 

56% 

82% 

Conception 

5% 

27% 

13% 

Codage 

7% 

7% 

1% 

Intégration 

Tests 

15% 

10% 

4% 

Maintenance 

67% 
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Modèles linéaires et incrémentaux 


o Modèles linéaires 
® cascade 
o modèle en V 

o ... 

o Modèles non linéaires 
® prototypage 
® modèles incrémentaux 
® modèle en spirale 

o ... 
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Processus de développement d’un logiciel 
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Le cycle de vie en « Cascade » 



9 Adapté pour des projets de petite taille, et dont le domaine 
est bien maîtrisé 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Le cycle de vie en « V » 



9 Adapté pour des projets dont le domaine est bien maîtrisé 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 
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Le prototypage 


9 Prototype : version d’essai du logiciel 

© Pour tester les différents concepts et exigences 
© Pour montrer aux clients les fonctions que l’on veut mettre en 
œuvre 

9 Lorsque le client a donnné son accord, le développement suit 
souvent un cycle de vie linéaire 

9 Avantages : Les efforts consacrés au développement d’un 
prototype sont le plus souvent compensés par ceux gagnés à 
ne pas développer de fonctions inutiles 
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Le modèle incrémental de Parnas 


O Concevoir et livrer au client un sous-ensemble minimal et 
fonctionnel du système 

Q Procéder par ajouts d’incréments minimaux jusqu’à la fin du 
processus de développement 

O Avantages : Meilleure intégration du client dans la boucle, 
produit conforme à ses attentes 


< □ ► < g ► < = ► < = ► '0 0,0 

m 


Pi< 


Gérard 


MERISE 




Processus de développement d’un logiciel 
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Le modèle en Sprirale de Boehm 


9 Un modèle mixte 

9 A chaque cycle, 
recommencer : 

O Consultation du client 
O Analyse des risques 
Q Conception 
O Implémentation 
O Tests 

O Planification du 
prochain cycle 


CUMMULATIVE i 



9 Avantages : meilleure maîtrise des risques, mais nécessite une 
(très) grande expérience 
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Modèles conceptuels 
Modèles organisationnels et logiques 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 

Méthode : une démarche et i 

jn formalisme 


9 Démarche : succession d’étapes pour 

® Mieux maîtriser le déroulement d’un projet 
9 Meilleure visibilité pour les utilisateurs sur certains résultats 
intermédiaires et garantir que le résultat final sera celui attendu 

9 Formalisme défini par: 

9 Un langage formel 

9 Un langage semi-formel généralement graphique 
9 Un langage naturel 

9 Fonction : 

9 Représenter le monde réel tel qu’il est perçu par le concepteur 
9 Outil de communication entre informaticiens et utilisateurs 
9 Constitué par un ensemble de modèles permettant d’assurer 
une bonne compréhension des besoins des utilisateurs 
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Processus de développement d’un logiciel 
La méthode MERISE 
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Modèles 


9 Représentation abstraite de la réalité qui exclut certains 
détails du monde réel 

9 Permet de réduire la complexité d’un phénomène en éliminant 
les détails qui n’influencent pas son comportement significatif 

9 Reflète ce que le concepteur croit important pour la 

compréhension et la prédiction du phénomène modélisé, les 
limites du phénomène modélisé dépendent des objectifs du 
modèle 


□ > < S ► < JF ' 4 = ► 'O 0,0 


Pierre Gérard MERISE 




Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


MERISE 


Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Méthode d’Etude et de Réalisation Informatique pour les 
Systèmes d’ Entreprise 

a Méthode Eprouvée pour Retarder Indéfiniment la Sortie des 
Etudes 

a MEthode pour Rassembler les Idées Sans Effort 
o Sutout lorsqu’on utilise un AGL 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 
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Approche Données / Traitements 


® Pour étudier et développer l’informatique d’une organisation, il 
est nécessaire de connaître: 

® comment elle réagit à une sollicitation externe 
® quelle est la structure des informations qu’elle utilise 

® MERISE modélise cette connaissance de manière duale : 

9 Modèles des Traitements (réaction aux événements...) 

9 Modèles des Données (vocabulaire de la structure...) 

9 Les 2 aspects sont complémentaires, synchronisés et validés 
entre eux 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Niveaux d’abstraction 


9 Pour chacun des problèmes de modélisation (données / 
traitements) 

9 Procéder de manière progressive... 

9 ... du plus stable au plus technique 
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Niveaux d’abstraction 


o Niveau Conceptuel 
9 Ce qu’il faut faire 
9 Quoi? 

o Niveau Organisationnel 
9 La manière de faire 
9 Pour les traitements 

® Niveau Logique 

9 Choix des moyens et ressources 
9 Pour les données 

9 Niveau Physique 

9 Les moyens de le faire 
9 Comment? 
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Niveaux d’abstraction 


Invariant / Stable 


Variable 
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Exemples de niveaux d’abstraction 


9 Conceptuel 

® Le client effectue une demande de service à la compagnie pour 
assurer son véhicule. Cette dernière lui propose un devis 
9 Organisationnel 

® Un client effectue une demande de service à l’agence de son 
choix, par courrier, pour assurer un véhicule. Un agent de 
service concerné, si le client est fiable (consultation d’un fichier 
central inter assurances), prend contact par téléphone pour une 
visite à domicile (après 17 heures) afin d’examiner plus 
précisément ses besoins et établir un devis 
o Physique 

® Le fichier central inter assurances est accessible par internet. 
Les agences sont connectées au siège de la compagnie par 
liaison ADSL. Chaque agence dispose de micro-ordinateurs de 
type PC et peut traiter ses données en local grâce au SGBD 
Access 
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Le niveau Conceptuel 


9 Exprime les choix fondamentaux de gestion, les objectifs de 
l’organisation 

9 Décrit les invariants de l’organisation 
® Le métier de l’organisation 
9 Définit 

® Des activités 
® Des choix de gestion 
® Des informations 
9 Indépendamment 

o Des aspects organisationnels 
® Des aspects techniques de mise en oeuvre 
9 Du point de vue 

® Des traitements: objectif, résultat, règle de gestion, 
enchaînement 

® Des données: signification, structure, liens 
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Le Projet 
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Le niveau Organisationnel 


® Exprime les choix organisationnels de ressources humaines et 
matérielles 
® Définit: 

9 La répartition géographique et fonctionnelle des sites de travail 
(du point de vue des données et des traitements) 

9 Le mode de fonctionnement : temps réel ou temps différé 
9 La répartition du travail homme/machine (degré et type 
d’automatisation) 

9 Les postes de travail et leur affectation, 

9 La volumétrie des données 
9 La sécurité des données 

® Indépendamment des moyens de traitement et de stockage de 
données actuels ou futurs 

o Les opérations conceptuelles vont être décomposées au niveau 
organisationnel en une ou plusieurs opérations 

organisationnelles 
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Le niveau Logique 


o Exprime la forme que doit prendre l’outil informatique pour 
être adapté à l’utilisateur, à son poste de travail 

® Indépendamment de l’informatique spécifique, des langages de 
programmation ou de gestion des données 

« Introduit la notion d’outils en tant que fonction réutilisable 
a Décrit 

® Le schéma de la base de données (relationnel, hiérarchique ou 
réseau), cad les caractéristiques du mode de gestion des 
données 

® La répartition des D sur les différentes unités de stockage 
® Les volumes par unité de stockage 
® L’optimisation des coûts induits par le mode de gestion 
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Le niveau Physique 


9 Traduit les choix techniques et la prise en compte de leurs 
spécificités 

9 Répond aux besoins des utilisateurs sur les aspects logiciels et 
matériels. 

9 Définit complètement: 

a Les fichiers, les programmes 

a L’implantation physique des données et des traitements 
a Les ressources à utiliser 
a Les modalités de fonctionnement 
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Processus de développement d’un logiciel 
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Le Projet 
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Les modèles au niveau Conceptuel 


* Le Modèle Conceptuel des Données (MCD) 

9 Description des données et des relations en termes de 
9 Entité ou Individu 
9 Relation ou Association 
9 Propriétés ou d 'Attributs 

o Le Modèle Conceptuel des Traitements (MCT) 

9 Description de la partie dynamique du SI en termes de 
9 Processus 
9 Opérations 
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Processus de développement d’un logiciel 
La méthode MERISE 
Le Projet 


Les modèles aux niveaux Organisationnel et Logique 


9 Le Modèle logique de donnée (MLD) 

® Le modèle « CODASYL » si une orientation base de données 
réseau est choisie 

9 Le modèle « relationnel » si une orientation base de données 
relationnelle est choisie 
9 Le modèle « hiérarchique » 

9 Le Modèle Organisationnel des Traitement (MOT) 

9 Permet de représenter par procédure les phases et les tâches 
effectuées par chaque poste de travail 
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La méthode MERISE 
Le Projet 

Les Modèles au niveau Physi 

que 


o Le Modèle Physique des Données (MPD) 

® Spécifie les organisations physiques de données 
® Le Modèle Physique des Traitements (MPT) 

o Décrit les traitements réalisés pour chaque transaction (temps 
réel) ou chaque unité de traitement (temps différé) 
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Processus de développement 
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Modèles successifs produits 


EXISTANT . FUTUR 
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Processus de développement d’un logiciel 
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Organisation du projet 


® Par groupe de 5 étudiants : analyse complète du cas proposé 
« Pour chaque scéance de TD 

9 Conception du modèle demandé pour la scéance en question 
a A la fin de chaque scéance, l’enseignant collecte votre travail 
9 Au début de chaqué scéance 

9 L’enseignant vous rend le travail de la scéance précédente 
corrigé 

9 Vous prenez en compte les corrections pour les étapes 
ultérieures 

o La note finale est la somme des notes partielles obtenues à 
chaque scéance 
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Echéancier 


® Semaine : 

9 Compte rendu d'entretiens et MCC 
9 MCT 

9 VED pour chaque opération 
O MCD en 3 eme forme normale 
Q MOT 
O MPD 

O Génération d’une base de données 
O Synthèse 
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Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 

Modèle Conceptuel de Communication 
Modèle Conceptuel des Traitements 
Modèle Conceptuel des Données 
Formes normales d’un MCD 

Modèle Conceptuel de Communication (MCC) 

1 


o Représente, au niveau 
conceptuel, les échanges 
d’information entre les 
acteurs 


9 Première étape d’une étude de l’existant, pour modéliser les 
habitudes de travail dans l’organisation concernée 
9 Délimiter le domaine étudié 

9 Réduire la complexité en identifiant des sous problèmes traités 
individuellement 

9 Identifier les acteurs externes et internes 
9 Modéliser les échanges d’informations entre les différents 
acteurs 
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Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

Acteurs 


9 Représenté par un cercle libellé par le nom de l’acteur 

9 L’acteur représente une unité active intervenant dans le 
fonctionnement d’un système opérant. Il peut 
o Etre stimulé par des flux d’information 
9 Transformer et émettre des flux d’information 

9 Un acteur « fait quelque chose », il est actif 
9 Ex : Service comptabilité, Guichet ... 

9 Un acteur est un rôle plutôt qu’une personne physique 
(« Direction » et pas « Jean-Claude ») 

9 II peut être pertinent de modéliser séparément deux fonctions 
assumées par une même personne physique 

9 On distingue les acteurs internes et externes 
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Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

Flux d'information 


® Représenté par une flèche entre deux acteurs, étiquetée par le 
nom du flux 

9 Echange d’informations entre deux acteurs 

® Ex : documents, appels téléphoniques, données informatiques 


Flux 1 


J 


Acteur B 


Flux 2 2 


Acteur A 


U- 


Flux 2 1 


Flux 3 


/ \ 

Acteur C ) 
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Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

Acteurs externes 


* Eléments externes avec lesquels le système échange des flux 
d’information 

o Ex : clients, fournisseurs... 


Acteurs externes 
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Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

Acteurs internes 


® Acteurs faisant partie du système d’information étudié 

9 Ex : guichet, service informatique... 

® Si le système est complexe, on peut considérer un acteur 
interne comme un sous-domaine et détailler ce sous-domaine 
dans un nouveau MCC 
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Modèle Conceptuel des Traitements (MCT) 


o Représente formellement les activités exercées par le domaine 
(à la base de la connaissance du SI) 

® Repose sur la prise en compte des échanges (flux) du domaine 
avec son environnement 

9 S’effectue en faisant abstraction de l’organisation et des choix 
technologiques 

La définition des interactions du domaine avec son environnement 
prime sur la manière dont on assurera ces activités 
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Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

MCC et MCT 


o Le MCT est un « zoom » sur le MCC 

® Dans les MCC, on représente les messages échangés entre 
acteurs 

9 Dans les MCT, on représente comment un acteur de 
l’organisation réagit quand il reçoit ce message et quelle 
opération il effectue 


Messages reçus à traiter 
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Modèle Conceptuel de 

Modèles conceptuels 

Modèle Conceptuel de 

Modèles organisationnels et logiques 

Modèle Conceptuel de 

Modèles physiques 

Formes normales d’un 


Modèle de MCT 


Evénement 
déclencheur A 

(a) 



i et b (Synchronisation) 


Nom de l'opération 


Action 1 
Action 2 
Action 3 


Règle d'émission 1 Règle d'émission 2 


/ \ 

f \ 

/ Evénement 

/ Evénement 

résultant C 

résultant C 

/ 

\ / 
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Exemple de MCT 



< □ 

m 


Pi« 


Gérard 


MERISE 


Communication 
s Traitements 
s Données 
MCD 





Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Passage du MCC au MCT 


Dossier incomplet 
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Formes normales d’un MCD 


Erreurs de modélisation fréquentes 


9 Règles d’émission : elles doivent 

9 Etre mutellement exclusives : deux règles de la même opération 
ne peuvent pas être vraies en même temps 
9 Couvrir tous les cas possibles 

9 Ne pas répéter les actions et les événements résultants 
9 Problèmes de synchronisation 

9 II faut simplifier les synchonisations 
9 Problèmes structurel 

9 II faut éviter les chaînes d’opérations et les événements internes 
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Simplification des synchronisations 


( A 

V ( a ) 


B 

(b) 


C 

(c) 


X* 


a ou (b et c) ou b 


Opération 
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Simplification des synchronisations 
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Simplification des synchronisations 


La simplification a mis en 
évidence que C n’était pas 
nécessaire 


A 

(a) 


B 

(b) 


C 

(c) 


< T > 

[ai ou bj 

Opération 


v 


< □ ► < g ► < 3 ► ◄ = ► '0 0,0 

m 


Pi« 


Gérard 


MERISE 





Introduction 

Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 


Simplification des synchronisations 


La simplification a mis en 
évidence que C n’était pas 
nécessaire 



Opération 



< □ ► < g ► < = ► < = ► '0 0,0 

m 


Pi< 


Gérard 


MERISE 





Introduction 

Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 


Réduction des chaînes d’opérations 



■ 


o De A à E, les opérations 
s’enchaînent de manière 
systématique 

« On supprime les 

événements internes B, C 
et D 
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Réduction des chaînes d’opérations 



( A ) 


S 


Opération 


Action OP1 
Action OP2 
Action OP3 


□ S 1 ~ 


Pi( 


Gérard 


MERISE 




Introduction 
Modèles conceptuels 
Modèles organisationnels et logiques 
Modèles physiques 


Autres exemples 



Chaînes à réduire à une seule 
opération 
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Gérard 


Modèle Conceptuel de Communication 
Modèle Conceptuel des Traitements 
Modèle Conceptuel des Données 
Formes normales d’un MCD 
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Cas d'introduction d’événements internes 


Traitement indisponibilité 


Pas dispo | Dispo et VAN < 30KE | Dispo et VAN >= 30KE 


Location 

impossible 


/ Demande de 
; caution 


Calculer la VAN ne se fait pas 
en cas d’indisponibilité 
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Cas d'introduction d’événements internes 


Traitement indisponibilité 


Pas dispo | Dispo et VAN < 30KE | Dispo et VAN >= 30KE 


Location 

impossible 


/ Demande de 
; caution 
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Modèle Conceptuel des Données 


a Modèle Entité / Association 

® Souvent nommé Entité-Relation 
a Repose sur les concepts de 
® Entités 
® Associations 
® Propriétés 

a Permet de décrire un ensemble de données relatives à un 
domaine défini afin de les intégrer ensuite dans une Base de 
Données 
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Formes normales d’un MCD 


Entité et entité type 


9 Entité Une entité est un objet, une chose concrète ou 
abstraite qui peut être reconnue distinctement 

® Ex : Jean-Claude, Momo, Ma Voiture, Son 4x4, Elle de 
France, la Bretagne 

9 Entité type : Une entité type est la représentation commune 
que l’on adopte pour des entités qui possèdent les mêmes 
caractéristiques 

o Ex : Personne, Voiture, Région 
Une entité est une occurence d’une entité type (ou instance) 


Personne 
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Modèles physiques 

Formes normales d’un MCD 


Propriété (ou attribut) 


9 Propriété : caractéristique associée à une entité type 

9 Ex : L’âge d’une personne, la puissance d’une voiture, le 
numéro d’un produit... 

9 On associe un domaine à chaque propriété, qui définit 

l’ensemble des valeurs possibles que peut prendre la propriété 

9 Valeur : Valeur que prend une propriété (à l’intérieur du 
domaine) pour une entité particulière 

9 Ex : 28 ans pour l’âge de Jean-Claude, 150cv pour la 
puissance de son 4x4 


Personne 

Nom 

Prénom 
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9 Association : lien entre plusieurs entités 

o Ex : Le mariage de Momo et de Jeanne, celui de Jean-Claude 
et d’Eglantine 

9 Association type : représentation d’un ensemble de relations 
qui possèdent les mêmes caractéristiques, lien entre plusieurs 
entités type 

® Ex : Le mariage de deux personnes 
9 Une association type peut avoir des propriétés 


Exopsant 


Stand 


Numéro exposant 
Nom exposant o,n 
Adresse exposant 
Catégorie 



Numéro stand 
Emplacement 
Surface 







9 Association : lien entre plusieurs entités 

9 Ex : Le mariage de Momo et de Jeanne, celui de Jean-Claude 
et d’Eglantine 

9 Association type : représentation d’un ensemble de relations 
qui possèdent les mêmes caractéristiques, lien entre plusieurs 
entités type 

9 Ex : Le mariage de deux personnes 

9 II peut y avoir plusieurs associations type liant les mêmes 
entités si la sémantique est différente 


Personne 0,n 



Propriétaire 



Appartement 


Numéro personne 

Nom 

Prénom 


An 


Numéro appartement 

Etage 

Escalier 

Porte 


? Locataire \ 






Introduction 

Modèle Conceptuel de Communication 

Modèles conceptuels 

Modèle Conceptuel des Traitements 

Modèles organisationnels et logiques 

Modèle Conceptuel des Données 

Modèles physiques 

Formes normales d’un MCD 

Abus de langage 


® Souvent, on parle d’« Entité » à la place d'« Entité Type ». 
Dans la suite, comme c’est d’usage, nous utiliserons les 
termes : 

9 Entité pour entité type 
9 Occurence d’entité pour entité 

® De même, on utilise souvent « Association » plutôt que 
« Association Type ». Dans la suite, comme c’est d’usage, 
nous utiliserons les termes : 

9 Association pour Association type 
9 Occurence d’association pour Association 
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Formes normales d’un MCD 

Identifiants 


9 Identifiant : une ou plusieurs propriétés d’une entité ou d’une 
association qui ont une valeur unique pour chaque occurence 
de l’entité ou de l’association 

9 Ex : Le numéro de SECU d’une personne, le numéro 
d’immatriculation d’une voiture... 

9 On souligne les identifiants d’une entité 
9 L’identifiant d’une association est un sous-ensemble des 
identifiants des entités liés 
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Cardinalités 


3 Cardinalité d’une association : le nombre de fois minimal et 
maximal qu’une occurence d’une des entités associée peut 
intervenir dans l’association 

9 Ex : un client peut commander entre 1 et n produits 
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Cardinalités 


Personne 


Appartement 


Immeuble 

Numéro personne 

/ Propriétaire '/ 

Numéro aooartement 

/ Fait partie \ 

Etage 

Escalier 

Porte 

Numéro immeuble 
Adresse 

Nom 

Prénom 

O.n \. J l.n 

1,1 V. ) O.n 


® Cardinalité minimale 

® 0 si une occurence de l’entité peut exister tout en 
n’intervenant dans aucune occurence de l’association 
® 1 si une occurence de l’entité ne peut exister que si elle 
intervient dans au moins une occurence de l’association 
® n : cas rare à éviter 
® Cardinalité maximale 

® 1 si une occurence de l’entité ne peut pas être impliquée dans 
plus d’une occurence de l’association 
® n si une occurence de l’entité ne peut être impliquée dans plus 
d’une occurence de l’association 
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Modèles organisationnels et logiques 

Modèle Conceptuel des Données 
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Formes normales d’un MCD 

Dimension d’une association 


o Dimension : Nombre de « pattes » de l’association 
9 Binaire, ternaire ou n-aire 


Exopsant 


Stand 

Numéro exoosant 
Nom exposant 
Adresse exposant 
Catégorie 

/Expose \ 

Numéro stand 

0,n t 1 0,n 

Emplacement 

Surface 



0,n 

i 

Salon 
Nom salon 
Date début 
Date fin 
Lieu 
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Types d'asociations 


® En fonction des cardinalités 

o 1:1 si toutes la cardinalités maximales valent 1 
® l:n s’il existe au moins une cardinalité maximale à n et une à 1 
9 n:m si toutes la cardinalités maximales valent n 
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Formes normales d’un MCD 

Associations réflexives 


o Association réflexive : Une association dont plusieurs 
« pattes » lient la même entité. Dans ce cas, plusieurs 
occurences de la même entité seront associées 


filiale 


Exopsant 
Numéro exposant 
Nom exposant 
Adresse exposant 
Catégorie 



groupe 


« On peut libeller chaque « pattes » par son rôle dans 
l’association 
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Remarques 


® Il est parfois difficile de faire un choix entre entité et 
association 

9 Ex : Un mariage est-il une association entre deux personnes ou 
une entité pour lequel on veut conserver un numéro, une date, 
un lieu, etc. et que l’on souhaite manipuler en tant que tel? 

9 Souvent, le contexte aide à décider 

9 Lorsqu’on ne parvient pas à trouver d’identifiant pour une 
entité, il faut se demander s’il ne s’agit pas en fait d’une 
association. Si ce n’est pas le cas, un identifiant arbitraire 
numérique entier peut faire l’affaire 
9 Lorsque toutes les pattes d’une association portent la 

cardinalité 11, il faut se demander si ce type-association et les 
types-entités liés ne décrivent pas en fait un seul type-entité 
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Cohérence entre données et traitements 


9 A chaque opération, on associe un MCD partiel : une Vue 
Externe des Données 

® On s’assure ainsi que toutes les données nécessaires sont 
représentées 

9 Le MCD global est l’union de toutes les VED 

9 Pour chaque élément du MCD global, on vérifie que celui-ci 
est utilisé dans au moins une opération 

o On s’assure ainsi que seules les données nécessaires sont 
représentées 

9 On s’appuie souvent sur des documents existants pour réaliser 
les VED 
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Dépendances fonctionnelles 


3 Une propriété (ou un groupe de propriétés) Y dépend 
fonctionellement d’une autre propriété (ou groupe de 
propriétés) X si 

o Etant donné une valeur de X, il lui correspond une valeur 
unique de Y. On note 
9 X — > Y (X détermine Y) 

® Cette relation est transitive : si X — ► Y et Y — ► Z alors 
X->Z 

9 Cependant, on ne représente que les DF élémentaires 
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Dépendances fonctionnelles 


Patient 


Mutuelle 

SECU 
Nom patient 
Prénom patient 
Adresse patient 

/ Cotise à \ 

Code mutuelle 

0,1 -y j 1 ,n 

Nom mutuelle 
Adresse mutuelle 


Médecin 


Numéro médecin 
Nom médecin 
Prénom médecin 



Hospitalisation 
Date entrée 
Date sortie prévue 



Affection 


Code affection 

0,n 

Libellé affection 


9 Les propriétés non identifiantes d’une entité dépendent 
fonctionnellement de l’ensemble des identifiants 

o Ex : SECU — > Nom Patient, PrénomPatient, AdressePatient 
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Dépendances fonctionnelles 



® L’identifiant d’une association de type nm dépend 
fonctionnellement des identifiants des entités liées 

® Ex : SECU, NuméroMédecin, CodeAffection — > DateEntrée, 
DateSortie 
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Formes normales d’un MCD 


Dépendances fonctionnelles 



* Une cardinalité 11 ou 01 est la source d’une dépendance 
fonctionnelle de l'identifiant du côté 11 vers l’autre côté de 
l’association 

® Ex : SECU — > CodeMutuelle 
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l ere Forme Normale (IFN) 

1 


9 Toutes les entités et les association possèdent un identifiant 

9 Aucune propriété n’est à valeurs multiples (popriétés 
atomiques) 
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l ere Forme Normale (IFN) 

1 


« Toutes les entités et les association possèdent un identifiant 

9 Aucune propriété n’est à valeurs multiples (popriétés 
atomiques) 


Facture 

Numéro 

Date 

Liste des produits 


9 Ici, « liste des produits » n’est pas atomique, c’est une liste 
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9 Toutes les entités et les association possèdent un identifiant 

9 Aucune propriété n’est à valeurs multiples (popriétés 
atomiques) 
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2 e Forme Normale (2FN) 


9 Le modèle est en IFN 

9 Toutes les DF entre les propriétés sont élémentaires 

» Toute propriété n’appartenant pas à une clé ne dépend pas 
seulement d’une partie de son identifiant identifiant 
® Les propriétés d’une entité ne doivent dépendre que de 
l’identifiant de l’entité et non d’une partie de cet identifiant 
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2 e Forme Normale (2FN) 


9 Le modèle est en IFN 


9 Toutes les DF entre les propriétés sont élémentaires 



0,n 

i 

Mois 

Mois 

Année 


® Ici, d’après le schéma, 

NumEleve, Nom Matière, Mois, Année — > Moyenne 
o Or, NumEleve et NomMatière suffisent 
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Forme Normale (2FN) 


o Le modèle est en IFN 

® Toutes les DF entre les propriétés sont élémentaires 


Moyenne 

Moyenne 


Elève 


0,n" 


Num élève 

Nom élève 0,n 

Prénom éleve 


Contrôle 


V Note 


0,n 


Mois 


Mois 

Année 


0,n 


Matière 


0,n Nom matière 
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3 e Forme Normale (3FN) 


9 Le modèle est en 2 FN 

9 Toutes les DF entre les propriétés sont directes 

® Les propriétés d’une entité doivent dépendre de l’identifiant de 
l’entité de manière directe 

® Toute propriété n’appartenant pas à un identifiant ne dépend 
pas d’un attribut non identifiant 
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Formes normales d’un MCD 


3 e Forme Normale (3FN) 


9 Le modèle est en 2FN 

9 Toutes les DF entre les propriétés sont directes 


Voiture 

Immatriculation 

Couleur 

Type 

Puissance 

Marque 


9 Or, Type —> Marque , Puissance alors que Type n’est pas un 
identifiant 
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3 e Forme Normale (3FN) 


9 Le modèle est en 2 FN 

9 Toutes les DF entre les propriétés sont directes 


Voiture 


Modèle 

/ De type \ 

1,1 ( — O.n 

Type 

Marque 

Puissance 

Immatriculation 

Couleur 
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3 e Forme Normale (3FN) 


9 Le modèle est en 2FN 

9 Toutes les DF entre les propriétés sont directes 


Voiture 

Immatriculation 

Couleur 


/ De type \ 


Modèle 

lYJDe 

u,n Marque 
Puissance 


9 Très bien mais si on voulait rajouter un numéro de facture... 
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Formes normales d’un MCD 


3 e Forme Normale (3FN) 


9 Le modèle est en 2FN 

9 Toutes les DF entre les propriétés sont directes 


Exopsant 


Facture 

Numéro exoosant 

j Numéro facture 

Nom exposant 

Montant 

Adresse exposant 

°’ n l Date 

Catégorie 

\ Réglée 



o!n 



Salon 



Nom salon 
Date début 
Date fin 
Lieu 


9 Or, NumFact — > Montant , Date, Réglée alors que NumFact 
n’est pas un identifiant 
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3 e Forme Normale (3FN) 


9 Le modèle est en 2FN 

9 Toutes les DF entre les propriétés sont directes 


Exopsant 


Facture 

Numéro exposant 
Nom exposant 
Adresse exposant 
Catégorie 

/ Facturation client \ 0,n 

Numéro facture 
Montant 
Date 
Réglée 

ôsT T 


On 


Salon 



Nom salon 
Date début 
Date fin 
Lieu 

f Prestation concernée \ 

0,n 1 J 
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Forme normale de Boyce-Codd (BCNF) 


9 Le modèle est en 3FN 

9 Les seules dépendances fonctionnelles élémentaires sont celles 
dans lesquelles un identifiant détermine une propriété 
9 Pour les identifiants composés de plusieurs propriétés, ces 
dernières ne doivent pas être dépendantes d’une autre 
propriété de l’entité (pour éviter les cycles de DF) 
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« Le modèle est en 3FN 

« Les seules dépendances fonctionnelles élémentaires sont celles 
dans lesquelles un identifiant détermine une propriété 


Vin 

Cru 

Pays 

Région 


o Or, Région —> Pays 
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9 Le modèle est en 3 FN 

9 Les seules dépendances fonctionnelles élémentaires sont celles 
dans lesquelles un identifiant détermine une propriété 


Cru 

( Elevé dans \ 0,n 

Région 

Cru 

Réaion 

Pays 

^ T 


® On a alors, Cru — ► Région et Région — ► Pays 
9 Attention : Même si elle peut être retrouvée par jointure, on a 
perdu la dépendance Cru , Pays — ► Région 

Un MCD ne doit pas nécéssairement être en BCNF, il faut peser 
le pour et le contre avant de perdre des dépendances fonctionnelles 
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ON DE LA BASE 


r 


ONNEES 


Dépendances fonctionnelles 
Formes normales 


^ LA NORMALISATION & 

DÉPENDANCES 

MHronctionnelles 

□ Le processus de normalisation permet de construire 
des bases de données relationnelles en évitant les 
redondances et en préservant l’intégrité des 
données. Il est préférable de normaliser les relations 
au moins jusqu’à la troisième forme normale. 

0 La normalisation est basée sur les dépendances 
fonctionnelles (DF). E.F. Codd fut le premier à 
publier des écrits sur les DF 




FONCTIONNELLES: 
DÉFINITION 


□ Un attribut b dépend fonctionnellement d'un 
attribut a si à une valeur de a correspond au 
plus une valeur de b. La dépendance fonctionnelle 
est notée a b. 

m Le membre droit de récriture s appelle le 
dépendant, le membre gauche s'appelle le 
déterminant. 




DEPENDANCES FONCTIONNELLES 


■■M 


□ Exemple : 

■ l'écriture tPilote,jour nbHeuresVol est 

une DF, car à un couple (numPilote, jour) 
correspond au plus un nombre d'heures de vol; 

■ l'écriture numPilote nomPilote, fonction 

est équivalente aux écritures numPilote 
nomPilote et numPilote fonction qui sont 
deux DF. En conséquence 

■ numPilote nomPilote, fonction est une DF ; 


FONCTIONNEL! 


: DEFINITION 


h DF élémentaire 

■ Une DF a,b—>c est élémentaire si ni a—*c, ni b—>c ne 
sont des DF. 

0 DF directe 

■ Une DF a —*■ c est directe si elle n'est pas déduite par 
transitivité, c'est-à-dire s'il n'existe pas de DF a — > b 
et b — ► c. 



s Exemple 


Considérons l'exemple qui fait intervenir les attributs 
suivants : (immat : numéro d'immatriculation d'un 
avion ; type Avion : type de l'aéronef ; nomConst : 
nom du constructeur). 

• La dépendance immat — > nomConst n'est pas une 
DF directe. 

• La dépendance immat — >• typeAvion est une DF 
directe. 

• La dépendance typeAvion — > nomConst est une DF 
directe. 



DEPENDANCES FONCTIONNELLES 

PROPRIÉTÉS : 

rpïïres d’Armstrong » ou « règles d’inférence » 


■ Réflexivité : si b est un sous-ensemble de a alors a — » b 
est une DF. Une autre écriture de la réflexivité (appelée « 
autodétermination ») a— ► a est une DF, 

■ Augmentation : si a— > b est une DF, alors a,c—> b, c est 
une DF. 

■ Transitivité : si a — > b et b — > csont des DF, alors a — > c 
est une DF. 

■ Union : si a — > b et a — > c sont des DF, alors a — > b,c est 
une DF. 

■ Pseudo-transitivité : si a — > b et b,c — > c/sont des DF, 
alors a,b^> de st une DF. 

■ Décomposition : si a — >■ b, c est une DF, alors a — > b et a 
— > c sont des DF. 


Formes normales 


La normalisation permet de construire 
des schémas optimaux en terme 
d'intégrité et de cohérence des données 
stockées. 



Formes normales : 
Première forme normale 

b ùon est en première forme normale si 

l chaque n-uplet contient une seule valeur par 
I jk attribut. 

h En d'autres termes, au niveau de l'extension 
d'une relation, à l'intersection d'une ligne et 
d'une colonne, on ne doit trouver qu'une et une 
seule valeur (qui peut être diverse : nombre, 
chaîne de caractères, date, image, etc.) 



Formes normales : 

^Bpeux/eme forme normale 

Une relation est en deuxième forme normale si 

î. le est en première forme normale, 

2. tout attribut n appartenant pas à la clé 
primaire est en dépendance fonctionnelle 
^élémentaire avec la clé. 


Formes normales : 

Wf^rorsrème forme normale 

s relation est en troisième forme normale si elle 

respecte la deuxième forme normale et si les 
dépendances fonctionnelles entre la clé 
primaire et les autres attributs sont directes. 


